A rudimentary Atari BASIC program ready to run |
|
| Developer(s) | Shepardson Microsystems |
|---|---|
| Stable release | Revision C / 1983 |
| Operating system | Atari 400/800/XL/XE |
| Type | BASIC |
| License | Copyright © 1979 Atari Inc. Proprietary |
Atari BASIC is a BASIC interpreter for the Atari 8-bit family of 6502-based home computers. The interpreter originally shipped on an 8 KB cartridge; on later XL/XE model computers it was built in, with an option to disable it, and started when the machines were booted with no other cartridges in place. The complete commented source code and design specifications of Atari BASIC were published as a book in 1983.[1] This marked the first time source code was made available for a commercial language.
Contents
|
In the nomenclature of the time when these machines were designed, "K" was taken to mean one kilobyte, so that is how it is expressed here. Similarly, further, on the family of processors use by Atari machines, in the assembly language "$" introduced a hexadecimal number, or it was suffixed subscripted with its radix, so, for example, "one hundred and twenty-eight" is "12810", "$80", or "8016". If a number is expressed with no radix, decimal (10) is assumed, and a leading 0 does not imply octal. These are used instead of more modern conventions because they appear as such in many of the sources and will be seen often by those using simulators and so forth.
The machines that would become the Atari 8-bit family had originally been developed as second-generation games consoles intended to replace the Atari 2600. Ray Kassar, the new president of Atari, decided to challenge Apple Computer by building a home computer instead. This meant Atari needed the BASIC programming language, then the standard language for home computers.
Atari did what many of the other home computer companies did: they purchased the source code to the MOS 6502 version of Microsoft 8K BASIC, intending to port it to run on their new machines. But the name was something of a misnomer, as the 8K referred to its original size on the Intel 8080's instruction set. The lower code density of the 6502 expanded the code to about 9 kB.
Atari felt that they needed to expand the language to add better support for the specific hardware features of their computers, similar to what Apple had done with their Applesoft BASIC. This increased the size from 9K to around 11K. Atari had designed their ROM layout in 8K b/locks, and paring down the code from 11K to 8K turned out to be a significant problem. Adding to the problem was the fact that the 6502 code supplied by Microsoft was undocumented.
Six months later, they were almost ready with a shippable version of the system. But Atari had a deadline with the Consumer Electronics Show (CES) approaching and decided to ask for help.
In September 1978 Atari asked Shepardson Microsystems (SMI) to bid on completing BASIC. Shepardson had written a number of programs for the Apple II family, which used the same 6502 processor, and were in the middle of finishing a new BASIC for the Cromemco S-100 bus machines (Cromemco 32K Structured BASIC). SMI examined the existing work and decided it was too difficult to continue paring it down; instead they recommended developing a completely new version that would be easier to fit into 8K. Atari accepted the proposal, and when the specifications were finalized in October 1978, Paul Laughton and Kathleen O'Brien began work on the new language.
The result was a rather different version of BASIC, known as ATARI BASIC. In particular, the new BASIC dealt with character strings more like Data General's BASIC than Microsoft's, which used strings similar to those from DEC BASIC.[2]
The contract specified a delivery date on or before April 6, 1979 and this also included a File Manager System (later known as DOS 1.0). Atari's plans were to take an early 8K version of Microsoft BASIC to the 1979 CES and then switch to the new Atari BASIC for production. Because of a bonus clause in the contract, development proceeded quickly and an 8K cartridge was available just before the release of the machines. Because Atari BASIC was delivered before Microsoft BASIC, Atari took it with them to the CES.
Shepardson's programmers found problems during the first review and managed to fix some of them, but Atari had already committed ATARI BASIC to manufacturing, and the technology of the time did not permit changes. So it was manufactured with known bugs, and became known (as a retronym) Revision A.
A BASIC programmer can find out the version by examining a well-known location in memory. Entering the command PRINT PEEK(43234) at the READY prompt will give a result of 162 for Revision A, 96 for Revision B, and 234 for Revision C.
Atari BASIC uses a line editor, like most BASICs of the era. Unlike many BASICs, however, Atari BASIC immediately checks the line for syntax errors. If a problem is found it shows the line again, highlighting the text near the error in inverse video. This can make catching syntax errors on the Atari much easier than on other editors; most BASICs will not display the errors until the program is executed. (The Sinclair ZX family of machines also adopts the approach of checking each line as it was entered, although it differs by not even allowing the line to be entered until it is syntactically correct, which can be a hindrance to the programmer when writing a line of code but wanting to look up something elswehere in the program.)
When not running a BASIC program, the Atari is in direct mode or immediate mode. Program lines can be entered by starting with a line number, which will insert a new line or amend an existing one. Lines without a line number are executed straight away, hence the name immediate mode.
When the programmer types RUN the program executes from the first statement. It can also be given a line number, so that RUN 2000 will run the program from line 2000, or the first line after that if line 2000 does not exist.
Unlike most other BASICs, Atari BASIC allows all commands to be executed in both modes. For instance most BASICs only allow LIST to be used in immediate mode, while Atari BASIC also allows it to be used inside a program. This is sometimes used as part of a way to produce self modifying code.
Program lines ("logical lines") can be up to three screen lines ("physical lines") of 40 characters, so 120 characters total. The cursor can be moved freely in these lines, unlike in other BASICs where to get "up" a line one has to continuously scroll leftwards until the cursor is wrapped at the left margin (and similarly to go down when wrapping at the right margin) – though that works too, except the cursor when wrapping left to right or right to left does not move up or down a line. The OS handles tracking whether a physical line flowed to the next on the same logical line; the three-line limit is fairly arbitrary but keeps lines below 128 characters and so reduces the chances of buffer overflow.
The cursor can always be moved freely around the screen, and it will wrap on all sides. Hitting "ENTER" will send the tokenizer the (logical) line on which the cursor sits. So, in the example pictured above (with "PRUNT"), all the author needs to do to fix the error is move the cursor over the "U", type <kbd class="keyboard-key" style="border: 1px solid; border-color: #ddd #bbb #bbb #ddd; border-bottom-width: 2px; -moz-border-radius: 3px; -webkit-border-radius: 3px; border-radius: 3px; background-color: #f9f9f9; padding: 1px 3px; font-family: inherit; font-size: 0.85em; white-space: nowrap;">I</kbd> (the editor only has an overwrite mode) and hit <kbd class="keyboard-key" style="border: 1px solid; border-color: #ddd #bbb #bbb #ddd; border-bottom-width: 2px; -moz-border-radius: 3px; -webkit-border-radius: 3px; border-radius: 3px; background-color: #f9f9f9; padding: 1px 3px; font-family: inherit; font-size: 0.85em; white-space: nowrap;">↵ Enter</kbd>.
This is quite a frequent editing technique for, say, renumbering lines. Atari BASIC has no built-in renumbering command, but one can quickly learn to overwrite the numbers on a set of lines then just hit "ENTER" repeatedly to put them back into the program. Indeed, a slightly cryptic but essentially simple idiom allows this to be done by the program itself as it is running, producing self-modifying code. This is not an artifact or cheat around the system but inherent in the combined behavior of the editor and tokenizer.
The Atari variation on ASCII, called ATASCII, has 128 (8016) characters mostly corresponding to ASCII but with a few exceptions. All characters have printable forms unlike ASCII where codes 0-31 (0-1F16) are "control codes" that perform special functions such as requesting a paper feed or ringing an attention bell. Characters 128-255 (8016-FF16) are displayed as the inverse video of characters 0-127 (0016-7F16). Variable names must be composed of upper-case alphabetic (65-90, 4116-5A16) and numeric (48-57, 3016-3916) characters, starting with an alphabetical character, and for strings terminating with a dollar sign (36, 2416).
The character set has a full ensemble of lower case characters and some graphics characters, but it is frequent to see programs mostly in upper case. This may be simply because of conventions, previous machines such as the Apple II series not having lower case; or that some devices such as daisy wheel printers may not have lower case; or that the lower-case font is not very attractive, in particular struggling to squeeze ascenders and descenders into the 8×8 fixed grid used to define each glyph, or the 8×7 fonts used on many dot matrix printers such as Atari's own.
On Revision C ROMs there is an alternative font including characters with diacritics, intended for European users, but this is rarely used. Adding user-defined fonts is relatively easy and each takes 1 kilobyte (128 characters × 8 bits high × 8 bits wide).
The ANTIC chip uses one byte to indicate the start page of a font (the memory consisting of 256 pages of 256 bytes). But only one font can be used at a time without machine code display list interrupts to change the font midway down the screen. Similarly on later GTIA graphics processors, a little-known 8×10 font mode exists, where two lines top or bottom of a character are assumed blank, thus keeping the actual glyphs to 8×8 but allowing ascenders or descenders without these characters touching those above or below; this is very rarely used, partly because dot matrix printers can not easily support it.[4] The ease of implementing other fonts means many are freely available, with font editors and so forth too.
Like most BASIC interpreters, Atari BASIC uses a token structure to handle lexical processing for better performance and reduced memory size. The tokenizer converts lines using a small buffer in memory, and the program is stored as a parse tree.[5] The token output buffer (addressed by a pointer at LOMEM – 80, 8116) is 1 page (256 bytes) long, and any tokenized statement that is larger than the buffer will generate a BASIC error (14 – line too long). Indeed, the syntax checking described in the "Program editing" section is a side effect of converting each line into a tokenized form before it is stored. Sinclair BASIC uses a similar approach, though it varies between models.
The output from the tokenizer is then moved into more permanent storage in various locations in memory. A set of pointers (addresses) indicates these locations: variables are stored in the variable name table (pointed to at VNTP – 82, 8316) and the values are stored in the variable value table (pointed to at VVTP – 86, 8716). Strings have their own area (pointed to at STARP – 8C, 8D16) as does the runtime stack (pointed to at RUNSTK – 8E, 8F16) used to store the line numbers of looping statements (FOR...NEXT) and subroutines (GOSUB...RETURN). Finally, the end of BASIC memory usage is indicated by an address stored at MEMTOP – 90, 9116) pointer.
By indirecting the variable names in this way, a reference to a variable needs only two bytes to address its entry into the appropriate table; the whole name does not need to be stored each time. This also makes variable renaming relatively trivial if the program is in storage, as it is simply a case of changing the single instance of its name in the table and the only difficulty is if the name changes length (and even then, only if it gets longer): indeed, obfuscated code can be produced for a finished program by renaming variables in the name tables – possibly all to the same name. This doesn't confuse the interpreter since internally it is using the index values not the names. Of course, new code will be difficult to add because the tokenizer has to search the name table to find a variable's index, and can get confused if names are not unique (though it is OK to have names in both the "string" and "variable" namespaces, e.g. HELLO = 10 and HELLO$ = "WORLD", because they have separate tables, that is to say, separate namespaces.)
Atari BASIC uses a unique way to recognize abbreviated reserved words. In Microsoft BASIC there are a few predefined short forms, (like ? for PRINT and ' for REM). Atari BASIC allows any keyword to be abbreviated using a period, at any point in writing it. So L. will be expanded to LIST, as will LI. and (redundantly) LIS.. To expand an abbreviation the tokenizer will search through its list of reserved words and find the first that matches the portion supplied. To improve the chance of a programmer's correctly guessing an abbreviation, to save typing, and to improve the speed of the lookup, the list of reserved words is sorted to place the more-commonly used commands first. REM is at the very top, and can be typed in just as .. This also speeds lexical analysis generally, since although the time to search is in theory proportional to the length of the list, in practice it will find common keywords very quickly, to the extent that good programmers know when a line is syntactically incorrect even before the parser says so, because the time taken to search the list to find it wanting gives an indication that something is wrong.
So whereas Microsoft BASIC uses separate tokens for its few short forms, ATARI BASIC has only one token for each reserved word – when the program is later LISTed it will always write out the full words (since only one token represents all possible forms, it can do no other). There are two exceptions to this: PRINT has a synonym, ?, and LET has a synonym which is the empty string (so 10 LET A = 10 and 10 A = 10 mean the same thing). These are separate tokens, and so will remain as such in the program listing.
Some other contemporary BASICs have variants of keywords that include spaces (for example GO TO). Atari BASIC does not. The main exception here is keywords for communicating with peripherals (see the "Input/Output" section, below) such as OPEN # and PRINT #; it rarely occurs to many programmers that the " #" is actually part of the tokenized keyword and not a separate symbol; and that for example "PRINT" and "PRINT #0" are the very same thing,[6] just presented differently. It may be that the BASIC programmers kept the form # to conform with other BASICs (The syntax derives from Fortran), though it is entirely unnecessary, and probably a hindrance, for tokenizing, and is not used in other languages for the Atari 8-bit family.
Expanding tokens in the listing can cause problems when editing. The Atari line input buffer is three lines (120 characters); up to three "physical lines" make one "logical line". After that a new "logical line" is automatically created. This doesn't matter much for output but it does for input, because the operating system will not return characters to the tokenizer after the third line, treating them as the start of a new "logical line". (The operating system keeps track of the mapping between physical and logical lines as they are inserted and deleted; in particular it marks each physical line with a flag for being a continuation line or a new logical line.) But using abbreviations when typing in a line can result, once they have been expanded on output, to a line that is longer than three lines and, a more minor concern, some whitespace characters can be omitted on input, so for example PRINT"HELLO" will be listed as PRINT "HELLO", one character longer. If one then wants to edit the line, now split across two logical lines, one must replace the expanded commands back with their abbreviations to be submit them back to the tokenizer. The moral of this is, generally, don't try to squeeze more out of a line than is reasonable, or, in the alternate, obfuscate variables by makinggggggthemverrrryverrrrylongindeed.
Literal line numbers in statements such as GOTO are calculated at run time using the same floating-point mathematical routines as other BASIC functions. This calculation allows subroutines to be referred to by variables: for instance GOTO EXITOUT is as good as GOTO 2000, if one sets EXITOUT to 2000. This is much more useful than it might sound; literals are stored in the 6-byte floating-point variable format, but variables are stored as a two-byte pointer to their place in the variable value table, at VVTP, so by using a variable the GOTO target is just two bytes instead of six. Of course the actual number takes another six, but this is only stored once, so if the same line number is used more than twice, one saves some memory, though the line number takes a little longer to look up. (The design choice to store what can only legally be integers as floating-point numbers is discussed below.)
It is quite common in BASIC to use GOTO or GOSUB to a line number, so real savings can be made to replace these numbers with variables. It also means that if the programmer is careful always to use the variable and not the literal, subroutines can be easily renumbered (moved around in the program), because only the variable value needs to be changed. This makes it common to see, at the start of an Atari BASIC program, a sequence of LET statements assigning line numbers to variables.[7]
Atari BASIC differs dramatically from Microsoft-style BASICs in the way it handles strings. In BASICs following the Microsoft model, strings are special types that allow for variable length and various operations. Atari BASIC has no strings of this sort, instead using arrays of characters, rather like Fortran. This allowed the BASIC language programmers to remove all the special-purpose code needed for handling dynamic resizing of strings, reusing instead the code already being used to handle arrays of numbers. A string is allocated a maximum size using the DIM statement, although its actual length can vary at runtime from 0 to this maximum size.
Of course, strings are not used by end programmers in the same way as arrays of numbers – at least not normally – so Atari BASIC also includes a selection of commands for "slicing" up arrays. A$ refers to the entire string, whereas A$(4,6) "slices" out the three characters 4, 5 and 6. In theory, this is a more elegant solution than Microsoft BASIC's LEFT$, MID$, and RIGHT$ solution, as this syntax replaces three separate commands with a single one.
Although this simplification reduces the size of Atari BASIC and offers some theoretical performance benefits, it is also a hindrance to porting BASIC programs from other computers to the Atari. When the Atari was first produced it was the norm for programs to be provided as listings in magazines for programmers to type in. They would have to scan them for instances of LEFT$, RIGHT$ and so on, do some mental arithmetic and replace them with slicing commands. Because strings were allocated a fixed size it generally means that programmers will pessimize or guesstimate the likely maximum size, allocating, perhaps 256 bytes for a string that only ever stores someone's first name.
Strings in Atari BASIC cannot themselves be members of arrays, so arrays of strings have to be implemented by the programmer. Strings can move around in memory, so it is not generally possible for example to store their memory addresses in an array. For short strings of approximately the same length, instead an array is generally built using padding so that the strings are all the same length and the nth string in the array is n×l characters into it, where l is the length of the string. According to Bill Wilkinson, the chief programmer at SMI, it was unfeasible to implement string arrays with strings that were larger than one page (256 characters).
The Atari OS includes a subsystem for peripheral device input/output (I/O) known as CIO (Central Input/Output). All I/O went through a central point of entry (E45C16) passing the address of an I/O Control Block (IOCB), a 16-byte structure that defines which device was meant, and what kind of operation (read, write, seek etc.). There are 8 such IOCBs, allocated at fixed locations in page 3 of memory from 38016 to 3FF16.
Most progams therefore can be written independently of what device they might use, as they all conform to a common interface – this was very rare on home computers when Atari BASIC was first made. virtual devices such as the screen, S: and the editor, E: did have special operations, for example to draw graphics or to ask for line input (in fact E: was pretty much a combination of S: and the keyboard, K:), but these were done in a uniform way and new device drivers could be written fairly easily that would automatically be available to ATARI BASIC and indeed any other program using the Atari OS, for example to provide support for new hardware devices such as mouse pointers, or software devices such as an 80-column display (using typically a 4×8 pixel font). Existing drivers could be supplanted or augmented by new ones since the driver table was searched newest-to-oldest, so a replacement E:, for example could displace the one in ROM to provide an 80-column display, or to piggy-back on it to generate a checksum whenever a line was returned – this technique is used for some of the program listing checkers that provide a checksum for each line.
Atari BASIC supports CIO access with reserved words OPEN #, CLOSE #, PRINT #, INPUT #, GET #, PUT #, NOTE #, POINT # and XIO #. There are routines in the OS for graphics fill and draw, but they are not available as specific BASIC keywords (e.g. DRAW or FILL, as in other BASICs), but can be got at through the general CIO entry point, which has the BASIC command XIO.
It is odd that a machine that is superlatively endowed with graphics capabilities did not expose them to BASIC, when they are already there in the hardware and the OS. One might assume the BASIC programmers ran out of time or space to add them to the BASIC tokenizer: they are available in variants such as Turbo-BASIC XL, and in other languages.
Up to eight IOCBs can be in use at a time, numbered 0 through 7 (0 was, by default, the editor E:). The BASIC statement OPEN # was used to prepare a device for I/O access:
REM Opens the cassette device on channel 1 for reading in BASIC OPEN #1,4,0,"C:MYPROG.DAT"
Here, OPEN # means "ensure channel 1 is free" (an error otherwise results), call the C: driver to prepare the device (this will set the cassette tape spools onto tension and advance the heads keeping the cassette tape player "paused"; the 4 means "for read" (other codes were 8 for write, 12 = 8 + 4 for "read-and-write", and so forth), and the third number provides extra auxiliary information, here not used and set by convention to 0. The C:MYPROG.DAT is the name of the device and the filename, as it happens, files on cassette were not named by this device. The string gives the device name and optionally a filename. Physical devices can have numbers (mainly disks, printers and serial devices), so "P1:" might be the plotter and "P2:" the daisy-wheel printer, or "D1:" may be one disk drive and "D2:" another, "R1:" may be a modem and "R2:" an oscilloscope (R for RS-232, provided by an add-on interface and not built into the OS), and so on; if not present, 1 is assumed.
ATARI BASIC disallows access to IOCB 0 (the editor, E:) and reserves IOCB 7 for printing and cassette operations using the built-in commands LPRINT, SAVE, LOAD, CSAVE, CLOAD, though there is nothing to stop printers or the cassette being used on other channels too. IOCB 6 is used for accessing the graphics screen device (S:) for drawing lines, filling shapes and so on. SAVE and LOAD output the compact tokenized form of the BASIC program, LIST and ENTER output and input the text source, just as if they were being sent to or from the editor.
For the other CIO functions, Atari BASIC uses the XIO statement. This just primes an IOCB and calls the CIO entry point; any of the other commands (PRINT, INPUT and so on) can be achieved with the more general form XIO.
But the form of XIO is not very friendly for BASIC users, and it is mostly used for unusual functions that are specific to a particular device. For example, an M: device exists called "Multi-Mouse"[8] that allows an Atari ST mouse, 8-bit trakball, touch tablet, or joystick, to be treated as a device whereby the position of the mouse cursor is set or got with NOTE and POINT commands. It should be remembered here that POINT does not mean, as it does in many BASICs, draw a point on the screen, but point a IOCB channel at a specific place in a file. In Atari DOS the two parameters to NOTE and POINT are the disk sector and offset, which is not very portable. In SpartaDOS they make up the offset from the start of the file. In the Multi-Mouse driver M:, they are the X and Y position of the mouse cursor.
I/O routines returned error codes of 128-255 (8016-FF16) via the processor's Y register and setting the carry flag of the processor. Setting the carry flag is a neat trick since the caller can immediately branch-on-carry (BCC or BCS instructions) to an error routine, a brief, quick and relocatable 6502 instruction (2 bytes, 2 cycles), without having to test Y for the (we hope) normal case where there is no error.
As with other aspects of the CIO, error codes were common across devices but could be extended for particular devices. Error handlers could thus be written quite generically, to fail gracefully, maybe put out a message, ask the user whether to retry, propagate the error, and so on.
There were no user-friendly messages for standard error codes in the OS itself. They would be interpreted by the application.
Atari BASIC (and other languages) thus had the freedom to return error codes less than 128, and these meant different things in different languages. There was nothing to stop a perverse implementer using error codes of 128 or above, but no incentive to do so.
The Atari 8-bit family of hardware includes quite a sophisticated graphics system, stemming from its basis in video games consoles.
Unlike many other home computers, the graphics "mode" – the size of pixels and the number of colors that could be displayed – is not fixed for the whole display but described line-by-line in a small microcontrol language to create a display list. Each entry in this list describes one or more lines on the TV display, top-to-bottom. A dedicated graphics microprocessor, "ANTIC", reads these out during the horizontal blanking interval to determine how to display the next TV line. Lines can be narrow (256 pixels wide at highest resolution), normal (320 pixels) or wide (384 pixels). Characters are 8×8 and one display list entry would thus describe 8 TV lines; the ANTIC keeps a counter (a shift register) of which line in the font to read the pixel data from for each of those lines, thus only requiring one entry for the whole 8 lines in the display. Similarly for larger, coarser graphics modes, the ANTIC chip kept track of the information so that it would display the data on more than one TV line.
The ANTIC thus has to reference the RAM and asserts control over the address bus and data bus to do so. This "steals" cycles from the main 6502 CPU. The Sinclair ZX81 had SLOW and FAST commands to switch the display off and on, because writing the display took about three quarters of the whole processor time. Because the Atari's display rendering is on a separate chip, even though it has to fetch memory, its impact on the main processor is generally negligible.
That being said, American machines are clocked to American NTSC video systems, at about 1.97 Mhz, to fit the 60 Hz vertical blank and correspondingly shorter horizontal blank; but European PAL models are clocked at 3 Mhz to fit a 50 Hz vertical blank. Because European machines have less work to do for the graphics output, and because of the higher clock rate, it makes them (as a rule of thumb) about 25% quicker than American ones.
Later (XL and XE) machines had an additional graphics processor called CTIA (later GTIA) offering additional modes, providing additional graphics modes, but for the purposes of discussing Atari BASIC these do not affect the basic description as they were programmed much the same way.
A hardware sprite system is also handled by ANTIC. A sprite is essentially a glyph 8 pixels wide and 256 TV lines tall, and has two colors: the background (0 in the glyph) and the foreground (1). ANTIC mixes the "foreground" color with the pixel beneath it, and displays the pixel "behind" the background color (that is, the main display) without change.
The sprite actually extends for the whole height of the display including the screen border. But the top and bottom are just a solid color. That is, the sprite is essentially a stripe down the screen where some bits can be turned on or off. It could be considered an extremely tall character in a font.
ANTIC will automatically overlay the sprite "stripe" at a horizontal position, so that where there is a 0 in the sprite definition the normal graphics pixel is displayed, but where there is a 1 the sprite color is mixed with the underlying color and the result of that mixing is displayed. Moving the sprite vertically is achieved by block moving (or rotating) the definition of its glyph in memory. This is painfully slow in Atari BASIC but is quite fast in the 6502 machine language, even though it lacks a block-move instruction like the 8080, because the sprite is exactly 256 bytes long and so the indexing can be easily accommodated in a byte-wide register on the 6502.
Although these sprites have quite severe limitations because of their width and color restrictions, careful use of them can make graphics programming, particularly games, significantly simpler since it reduces the need to manipulate display memory for fast-moving objects, such as the "player" and his weapons in a shoot 'em up game. The official ATARI name for the sprite system is indeed "Player/Missile Graphics".
There are five sprites; four "players" eight bits wide and four "missiles" two bits wide. But they can be overlapped to make multi-colored sprites, at the expense of reducing the number of sprites available for other uses.
The ANTIC microprocessor has many "registers" by which colors for them can be set, and to set their horizontal position and turn them on and off.
Colors generally are not specified as an RGB color but as an index into a palette. For example, for a four-colour graphics mode, only four colours can be displayed, numbered 0 to 3, but the color values can be chosen from any of the 256 in the physical color palette. For 2-color modes there is actually only one color, which can be displayed at two levels of luminance. Black-and-white works well here, as does the blue-on-blue that Atari uses by default, but for other colors it may not look so good.
The display list can specify for each line the address in memory from which to fetch the data (with some trivial memory alignment restrictions), but if this is not specified then ANTIC will fetch the data from the next address in memory from where it finished reading the previous line.
Short sections of machine language code can be executed during the horizontal blanking interval, and this is typically done to change the values in the color registers, horizontal sprite positions and so forth thus giving the appearance of more colors or more flexible sprites than the hardware provides ab initio. This machine code has to be very short as there are not many clock cycles available during each horizontal blank. These routines are known as DLIs (display list interrupts) but are simply off limits to Atari BASIC as it is far too slow to perform even the simplest of tasks. Strictly these should be called "DLI routines" but are usually just called "DLIs".
During the vertical blanking interval, a much longer interval, another interrupt is generated and the Operating System hooks into this to perform some housekeeping tasks. Again, this is not available to Atari BASIC directly, although with some manipulation and severe restrictions (because BASIC was not designed to be re-entrant) it is possible for a VBI (vertical blank interrupt) routine to call a BASIC routine. The VBI is a favourite place to stick some code that needs to execute frequently.
The operating System provided several standard "Graphics modes" by which it set up a display list automatically, and allocated memory, at the top end of free memory. These provided a range of graphics modes including text modes, graphics modes and mixed text-and-graphics modes. It was only these predefined modes that were available to Atari BASIC.
The lack of an OS routine for a general-purpose memory move routine perhaps exhibited in artifacts of the graphics design. For example, once a graphics channel had been opened, it was not possible (or at least easy) to move it down in memory so that other memory could be reserved above it, which meant that generally a program would allocate "more than enough" memory above the high memory pointer (HIMEM) then set the graphics mode (with the GRAPHICS statement) to have the operating system allocate memory for the display below the new high water mark.
Most of ANTIC's registers were write-only, their values could not be read (or rather they could be, but were meaningless or returned different values from those written as they were multiplexed). The Operating System kept copies of the values written in "shadow registers" in pages 0 and 2 of memory (page 1 was the hardware stack on 6502 processors), thus allowing programs to read the values. The values written here were rewritten to the ANTIC registers during the vertical blank interrupt.
The operating system provided access to the graphics in two ways: by allowing direct reads and writes (in Atari BASIC, through the PEEK and POKE commands to the memory being used to hold the graphics, by making available the address of the start of that memory in a well-known location, and to the shadow registers), and also by providing a CIO device, "S:", through which CIO commands could be issued. The S: device supported the general-purpose XIO command used to implement PLOT, DRAWTO and FILL (unfortunately the last was not exposed to Atari BASIC, and was also rather tricky to get right at the best of times, as it used a rather primitive scanline fill that filled lines left-to-right, bottom-to-top but stopped as soon as a boundary was met, rather than providing a full flood fill).
In a way there was some confusion and overlap here in the design. For example, the CIO NOTE and POINT commands could be considered analogous to reading and writing the position of the cursor, but instead they had a separate interface through well-defined memory locations. Thus the exposure of the graphics API to BASIC and other languages was perhaps not as orthogonal and device-independent as it could have been.
Atari BASIC supported graphics using the statements COLOR, SETCOLOR, CLEAR, PLOT, DRAWTO, LOCATE and GRAPHICS.
Because of the support provided by the operating system, Atari BASIC implemented most of its graphics statements as simple calls to those routines or just set the memory registers for the cursor position and so on. In many cases it simply left programmers to use PEEK and POKE statements. It could be argued that some statements such as SETCOLOR were not only redundant but confusing, since they simply set one color value in a shadow register and could be as easily, and more quickly, done with a POKE command; the ROM space used by these routines could perhaps have been better used to implement other things.
The lack of a FILL command is a notable omission considering that the routine, however primitive, was available in the operating system. It could be achieved with the general-purpose XIO command, but was rather fiddly:
REM The co-ordinates of the corners of the fill quadrilateral have to be set up REM before calling XIO, using POKE into the IOCB. This is quite a trick because REM it's not easy to find out where the IOCB is. Anyway, then we do: XIO 18,#6,12,0,"S:" REM XIO # = Extended IO. REM 18 = Fill (17=Drawto). REM #6 = On Channel 6, mapped to the graphics screen device. REM 12 = Read/write. REM 0 = Redundant (unused). REM "S:" = Logical device, used only for OPEN and some disk REM commands with a target such as for a RENAME REM Redundant here but used by convention
There was no BASIC support for sprites, although they were not particularly difficult to program in BASIC using PEEK and POKE, but this could not be done particularly fast in, say, games. Similarly, setting up a custom display list could be done, but was rather difficult, and was far more easily and effectively done in machine language. Sprite data could be defined using a DATA statement, and then POKEd into memory. However, scrolling a sprite vertically, for example, was not quick in BASIC as there was no "block memory move" statement and required a slow FOR loop of PEEKs and POKEs.
In comparison to the BASICs of some competing machines at the time, Atari BASIC had good built-in support of sound, (SOUND statement), graphics (GRAPHICS, SETCOLOR, COLOR, PLOT and DRAWTO) and peripheral units like joysticks (STICK, STRIG) and paddles (PADDLE, PTRIG). Other home computer users were often left with cryptic POKEs for such programming.
That being said, the parameters for many of these commands were cryptic, and essentially little better than machine code. SOUND took four numeric parameters for pitch, tone, volume and channel (the Atari 8-bits had 4-channel sound); the GRAPHICS statement took three to handle the numerous graphics modes, SETCOLOR and COLOR each took a number of parameters with different meanings depending on the graphics mode and often which did not match between the two, and so forth. It may be an example of Conway's law: clever designers made excellent hardware, by and large following a common model (memory-mapped register addressing for ANTIC, GTIA and Pokey, for example), but the lack of the teams' interaction made them work in curiously different ways. One may wonder why it would be thought so important to include two key words for examining the state of paddles – something that could be done easily with a single PEEK and indeed in every respect more efficiently than a PADDLE statement – yet not have a FILL command that was already coded in the OS and would have been uniquely advanced for the BASICs of the time.
Similarly, advanced aspects of the hardware such as sprites were completely out of bounds for BASIC programmers, and the lack of access to timers made sound programming difficult, particularly because North American machines ran on different clock speeds from the rest of the world (basically because they were tied to the speed of the television system).
Running on the original equipment, Atari BASIC is slower than other BASICs on contemporaneous equipment for the same home market, sometimes by a surprising amount, especially when one takes into account the fact that the Atari's CPU was clocked almost twice as fast as that of most other 6502-based computers of that era. Most of these problems stemmed from two particularly poorly implemented bits of code.
One is a side effect of how Atari BASIC recalculates line numbers as the program is run. This means that a GOTO has to run a small amount of additional code in order to find the line to jump to.[9] This would normally be a minor issue, but the same code is also used to implement NEXT in a FOR...NEXT loop, so it dramatically lowers performance of these very common loops (indeed, the only loop structure in Atari BASIC). It is obvious that a line number less than 6553610 (1000016) can be stored in a 16-bit unsigned integer, but presumably the designers chose to store it as floating point for other reasons.
Atari BASIC does not do well with integer variables; all numbers are stored as floating point. Atari BASIC relied on the Atari OS's built-in floating point routines (BCD notation), which are relatively slow compared to other representations, even on the same hardware. But most of the slowness of the implementation lies in a particularly poor implementation of the multiply subroutine used throughout the math libraries. This is really not a problem of the language itself but of the underlying OS, but it adds to the general poor performance. More spectactularly, really, the fact that simple integer operations are converted back and forth to floating point really highlights the flaw, especially considering that the Atari's best features rely on special hardware (for graphics, sound and so on) that deals purely in integers: bytes or two-byte words. There is not even in Atari BASIC an easy way to perform bitwise operations.
The MOS 6502 processor had a special mode for dealing with BCD (the SED and CLD instructions to treat each 4 bits of a byte as a BCD digit), and perhaps that was particularly attractive to the designers for implementing floating point as BCD. The now almost universal IEEE 754 standard of representation of floating point numbers was still at the design stage when the Atari 8 bit family and its contemporaries first came to market, so the design of an FP implementation was very much up to the OS or BASIC designer.
Several commercial and shareware BASICs were available on the platform that addressed some or all of these issues, resulting in performance that was 3 to 5 times faster than the Atari version. Using these BASICs, the Atari was one of the fastest home computers of its era.
Atari later sold a diskette-based version of Microsoft BASIC, Atari Microsoft BASIC, and later managed to fit it onto a cartridge as well, but no compiler or runtime was available for redistribution.
Despite its small footprint (8 kilobytes), Atari BASIC has some features that give it some powers of more-advanced, larger versions of BASIC.
Atari BASIC has no implementation of subroutines, or rather, it does not have a concept of local variables. In Fortran terminology, all variables are COMMON.
But programmers can simulate user functions because of the way the GOSUB command can reference a variable. For example, a programmer could start a subroutine at line 10000 and have the program initialize a variable with that number, e.g. LET TEST = 10000. The calling code can then initialize some mutually understood variables and use the statement GOSUB TEST to invoke the subroutine. The subroutine starting at line TEST can then do its operation on the predetermined variables and put return results into variables available after RETURN.
By extension, if the two agree on two variables, an array called, say, STACK and a numeric variable called STACKTOP, then a stack can be implemented in software whereby local variables are pushed and popped to the stack and so implement local variables. For example:
10 DIM STACK(100) 20 STACKTOP = 0 35 REM LINE NUMBERS OF SOME FUNCTIONS FOLLOW 40 FACTORIAL = 8000 60 PUSHSTACK = 2100 70 POPSTACK = 2200 75 REM LET'S COMPUTE EIGHT FACTORIAL 80 LET STACKVALUE = 8: GOSUB PUSHSTACK 90 GOSUB FACTORIAL 100 GOSUB POPSTACK 110 PRINT "EIGHT FACTORIAL IS "; STACKVALUE 120 END 2099 REM PUSHSTACK SUBROUTINE 2100 STACK(STACKTOP) = STACKVALUE: STACKTOP = STACKTOP + 1: RETURN 2199 REM POPSTACK SUBROUTINE 2200 STACKTOP = STACKTOP - 1: STACKVALUE = STACK(STACKTOP): RETURN 7999 REM FACTORIAL SUBROUTINE 8000 GOSUB POPSTACK 8010 IF STACKVALUE <= 2 THEN GOSUB PUSHSTACK: RETURN 8020 FACTORIAL = STACKVALUE 8030 STACKVALUE = STACKVALUE - 1: GOSUB PUSHSTACK 8040 GOSUB POPSTACK: FACTORIAL = FACTORIAL * STACKVALUE 8050 RETURN
BASIC or FORTRAN aficionados may notice that line 8010 can be optimized because a GOSUB followed by a RETURN is the same as a GOTO, because the subroutine will do the RETURN for us:
8010 IF STACK VALUE <= 2 THEN GOTO PUSHSTACK
This is of course a cute example of why the GOTO statement is Considered Harmful.
Because Atari BASIC can read in lines of code from any device, not just the editor, it is possible to save blocks of code and then read them in and merge them into a single program just as if they had been typed into the editor. Of course this means the lines being read in must have line numbers that are not used in the main program. The code to be merged is written to a device as text using the LIST command, and can be put back into the program with the ENTER command. So the stream of text on the device is, from the BASIC interpreter's point of view, no different from that had it been typed into the editor.
By carefully using blocks of line numbers that do not overlap, programmers can build libraries of subroutines (simulating functions as above) and merge them into new programs as needed.
Atari BASIC does not have a built-in assembly language processor. Machine code is generally stored as bytes in strings. Machine code functions are invoked from Atari BASIC with the USR statement, which works in much the same way as GOSUB, but with fewer guarantees.
String variables can hold any of the 256 characters available in the ATASCII character set and thus each byte of memory reserved for a string variable can hold any number from 0 to 255, including the characters 3410 (2216, "quote") and 15510 (9B16, "ENTER"), although these are tricky to type in. Short relocatable 6502 machine language routines can be converted to ATASCII characters and stored in the string variable. The machine language routine can be called as a function with the USR command specifying the address of the string variable as the location in memory to execute. For example, if the machine language code is stored in a string named ROUTINE$ it can be called with parameters as ANSWER=USR(ADR(ROUTINE$),VAR1,VAR2). Parameters are pushed onto the hardware stack (in Page 1) as 16-bit integers; variables are pushed as their addresses. The return value is in the A and X registers and interpreted by BASIC as a 16-bit integer; it cannot be pushed to the stack as there is no concept of a stack frame, and for the same reason there is no concept of a void return, but typically if the machine code subroutine does not return anything useful, the value – just whatever happens to be in those registers at the time – is just ignored.
These routines have to use relocatable machine code: that is to say, they cannot use instructions like JMP or JSR that use absolute addresses, except to well-known addresses in the OS and so forth; they can only use branch instructions such as BCC (branch if carry clear) which jump backwards or forwards by roughly 12810 (8016)[10] because the strings could be moved in memory. For this reason page 6 (060016–06FF16), a page of memory not used by BASIC or the operating system, is very popular for storing small routines; but of course one runs the danger that another routine may also wish to be stored there.
On the 6502, relocation is not trivial. These days we expect programs to sit pretty much anywhere in memory; the loader and processor collaborate to make that happen. But microprocessors of that era did not do that. The 6502 was especially hindered by having very few indirection instructions, and those it had were asymmetric: the X and Y registers indirect in different directions. This leads either to rather clumsy code that is forever moving stuff between registers, or clever but obtuse code that keeps them where they need to be even if it would seem more obvious to stick something else there. The 6502 instruction set is small enough that, over a short time, programmers can model the entire processor in their heads, even down to knowing how many cycles each instruction takes, and then start making clever tricks.
As well as using machine code for advanced functions, fairly trivial USR routines are sometimes used simply to gain access to functions in the Atari OS that have not been provided through Atari BASIC: for example block serialization to and from devices (Atari BASIC only lets it be done byte by byte, with GET and PUT, which takes far longer for just shuffling back and forth through the OS layers than actually writing the one byte of data), or for reading and writing blocks of memory (the PEEK and POKE commands were also unnecessarily slow because of the numeric problems described above).
Machine code can also be stored as numbers in DATA statements, but this is pathological in that a byte is then stored as a six-byte floating point number, plus several other overheads, simply to be placed somewhere else as a byte. This method is sometimes used for very short routines where size isn't important but ease of use is (no special loaders or clever typing routines are required), or for one-off programs that then write out the resulting block of bytes (probably stored in a string) is written out as a program that can be read in later byte-for-byte.
|
|
|
|
|
On the XL/XE models, Atari BASIC could be disabled by holding down the OPTION key while booting the computer. The XEGS would disable BASIC if powered without the keyboard attached.
If another cartridge were inserted it may also disable Atari BASIC, if they used the same address space.